Could we measure the performance cost of this? Maybe should this feature be put behind a flag?

Did I just spend 10 hours attempting to figure out why my other branch segfaults on 8.2 debian images and it's not actually related to my branch in the end?

Certainly seems like it...

Could we measure the performance cost of this? Maybe should this feature be put behind a flag?

I'll do benchmarks soon and we'll be able to see from there!

This is the impact, on already existing benchmark:

• HelloWorld:
  • main: 32.14us
  • branch: 33.17us
  • Delta: ~1us
• Echo:
  • main: 29.07us
  • branch: 29.02us
  • Delta: None
• ** ServerSuperGlobal**:
  • main: 62.15us
  • branch: 63.12us
  • Delta: ~1us
• ** UncommonHeaders**:
  • main: 59.20
  • branch: 60.12
  • Delta: ~1us

Also, 0 additional allocation is recorded on the hot path. The impact is negligible and the metrics newly exposed would really help better monitor how things are going while processing requests.

Also, 0 additional allocation is recorded on the hot path. The impact is negligible and the metrics newly exposed would really help better monitor how things are going while processing requests.

Sounds reasonable to me.

Out of curiosity, does anybody know of a per-route monitoring solution that exposes metrics like number of requests, php request duration, etc.? Much like Sentry, Datadog or Tideways, but without all the low-level insights?

Or perhaps that's a good candidate for a go php extension to hook into the runtime, gather the data, hand it to Go and add it to the prometheus metrics?

Not that I'm aware of, but an extension for this purpose could indeed be a good idea

Not that I'm aware of, but an extension for this purpose could indeed be a good idea

Time to implement something. I'll create a proof of concept (I think this may even be implemented entirely in Go) and perhaps we can merge it upstream later.

That was actually much simpler than I thought, only around 400 lines of code.

sub.domain.com {
	# need to handle this in the module somehow, not sure how yet
	handle /metrics {
		@denied not remote_ip 127.0.0.1 ::1 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
		respond @denied 403
		metrics
	}
	route_metrics {
		path /metrics
		pattern "/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}" "/:uuid"
		pattern "/(\d+)(/|$)" "/:id$2"
		pattern "^/.*" "$0"

		duration_buckets 1 5 10 25 50 100 250 1000
		status_buckets 204 403 418 # everything else falls in a 2XX or 4XX/5XX bucket
	}
}

@alexandre-daubois @henderkes 👋🏻 this PR/discussion really got my attention
obviously the more data/hint we have on the low level part of this runtime, the better and thank you to go in that subject :)

I got some questions:

@alexandre-daubois iiuc, this PR may outputs more data behind the /frankenphp/threads endpoint

• is that right ?
• If so, I see no documentation of such endpoint, is it intended to be only "internally visible"?
• may this endpoint return html and not json ? (thinking of the mercure gui for example for example)

@henderkes your last post 'pic looks very promising, it seems built on top of the metric of frankenphp/caddy and prometheus scrapping correct?
kind of same question as above, would it be possible to have such data visible as html somehow? I mean without all the infra layer of external monitoring

having, as a frankenphp/caddy module, such "low level visibility/monitoring tool" would be very valuable 👍🏻

I am writing/thinking out loud here, and not being really aware of go, frankenphp etc, I may miss some part ^^

thx !

is that right ?

Yes

If so, I see no documentation of such endpoint, is it intended to be only "internally visible"?

Nope, documentation should be done as well!

may this endpoint return html and not json ? (thinking of the mercure gui for example for example)

I don't think it should return HTML, I think it would be weird. FrankenPHP exports raw data, it's up to people to format them the way they want. Maybe with an external extension 🙂

• If so, I see no documentation of such endpoint, is it intended to be only "internally visible"?

No, it needs to be documented.

• may this endpoint return html and not json ? (thinking of the mercure gui for example for example)

Definitely json. Json is expected by prometheus.

@henderkes your last post 'pic looks very promising, it seems built on top of the metric of frankenphp/caddy and prometheus scrapping correct? kind of same question as above, would it be possible to have such data visible as html somehow? I mean without all the infra layer of external monitoring

No, that's app-specific prometheus metrics that can be visualised by Grafana or any other tool of your choice.

having, as a frankenphp/caddy module, such "low level visibility/monitoring tool" would be very valuable 👍🏻

I am writing/thinking out loud here, and not being really aware of go, frankenphp etc, I may miss some part ^^

I think you're missing Prometheus and Grafana :P

thx I will try to document such endpoint 👍🏻

I definitly got the metric over prometheus (what I described above)
but rather wanted to ask if it is a mandatory stack and if this kind of "data/dashboard" can be output without such tooling (json or html)

anyhow, thanks both of you @alexandre-daubois @henderkes cheers !

I checked and actually, the whole thing isn't documented yet at all. I'd rather see this one merged and take care of the exhaustive documentation for the /threads endpoint in a follow-up PR 🙂

Maybe we could create a third-party Caddy module embedding https://github.com/prometheus/prometheus/blob/main/web/ui/README.md and proxying the Caddy Prometheus API?

Yes, that's a good idea!